In IEEE802.16e, all the uplink services except UGS unsolicited grant service) connection require to request bandwidth from a base station BS. When data in a buffer of a mobile station MS await uplink transmission, the MS will do the above bandwidth request. The bandwidth request refers to a mechanism that the MS indicates to the BS that it needs how large bandwidth to proceed with the corresponding uplink transmission. The bandwidth request of the MS needs to take into account number of bytes to be carried by a MAC (medium access control) PDU (protocol data unit). When the BS receives the bandwidth request from the MS, it will consider available resource and a scheduling scheme to allocate resource to the MS. It is possible that the MS receives a transmission opportunity less than as anticipated, or cannot receive the UL grant from the BS. This might be caused by problems such as scheduling judgment, insufficient resource or missing of the request message. As for a failure to allocation resource matching the MS's requirement, the BS will not provide definite reasons.
FIG. 7 shows a bandwidth request/grant procedure provided in IEEE 802.16e. At step S701, once the MS needs to request a bandwidth, it selects a CDMA ranging code and provides, in a ranging slot for competition, the CDMA ranging code to the BS. At step S702, once the CDMA ranging code is detected, the BS provides CDMA_IE UL allocation information to the MS.
At step 703, the MS sends, in the allocated resource, a bandwidth request message to the BS. Then the BS should reply UL grant at step 704 to allocate the bandwidth resource requested by the MS. If the BS does not send the above UL allocation information, or the bandwidth request does not cause the BS to allocate the corresponding bandwidth in the subsequent steps in a designated time interval, the MS will assume that the bandwidth request fails and filed a bandwidth request again or discard the corresponding SDU.
After the MS sends the bandwidth request, it expects to receive the bandwidth allocation (UL grant) from the BS. However, in some cases the MS may not obtain the expected bandwidth allocation. One reason is that in some adverse network environments, the bandwidth request information might be discarded or destroyed. As shown in FIG. 8, after the sent bandwidth request message gets lost, the MS cannot sent a CDMA competition again unless the timer of the MS overflows. Therefore, the BS cannot correctly receive the bandwidth request message sent by the MS. This causes failure to send the UL grant message desired by the MS to the MS. Another reason relates to scheduling judgment. If the BS thinks that available resource cannot meet all the bandwidth requests, it is likely to decide to delay bandwidth allocation to some specific MSs, e.g., allocate bandwidth to theses MSs in the subsequent frames. As such, the BS can first meet the demands of some time-critical services. Even if the MS does not obtain the corresponding bandwidth allocation, the BS will not give definite explanations to the MS. The MS detects the invalid of the bandwidth request by judging whether the timer overflows. If a latency set by the timer has already passed and the MS does not receive the desired bandwidth allocation, the MS will re-initiate a new CDMA competition.
In the case that the bandwidth request message gets lost, the MS has to wait for an unnecessary period of time (namely, a period of time until the timer overflows) to re-send a bandwidth allocation request. This enlarges the latency of the bandwidth request. If the latency is configured to be relatively short, even if the BS correctly obtains the original request, the MS might re-send a bandwidth request message because the timer might overflow before the BS begins to schedule UL grant to the MS. This causes unnecessary overhead and causes the BS to mistakenly regard it as a new request, as shown in FIG. 9. The reason for this problem is that the BS that receives the bandwidth request message does not acknowledge the receipt of the message.
The IEEE 802.16m work group has already begun to amend the IEEE 802.16 standard in order to increase operation performance in granted channels for air interface. According to the required documents, this proposes stricter requirement for the bandwidth request: shorter latency and less overhead. Therefore, solution to the above problem becomes more important.
At 56th meeting of IEEE 802.16 (in July 2008), Intel Corporation proposes a solution (non-patent document 1: IEEE C80216m-08—635, BW-REQ channel design recommendations for IEEE 802.16m, Intel Corporation, Jul. 13, 2008) of enabling the MS to definitely acknowledge whether the BS receives the bandwidth request message to allow for restart of random access as soon as possible.
As shown in FIG. 10, at step 1001, when a buffer of the MS has data to be sent, the MS selects a corresponding ranging code for a CDMA competition. Then, once the BS receives the CDMA competition from the MS, it will carry out a corresponding CDMA_IE allocation, that is, allow the MS to know when or in what resource the MS should send a resource request message.
Thereafter, at step S1003, the MS, at the corresponding instant or resource, sends the resource request message. At step S1004, after the BS receives the resource request message from the MS, it makes a definite acknowledgement. Then, at step S1005, resource is scheduled on the side of the BS to allocate the requested resource to the MS and send it to the MS through UL grant information. At step S1006, once the MS receives the resource allocated by the BS, it will send, on the resource, the data to be sent in the buffer to the BS.
As compared with the procedure in IEEE 802.16e, the solution of the above non-patent document 1 adds the step of acknowledging the bandwidth request (step S1004 in FIG. 10). Once the BS receives the bandwidth request message from the MS, it will definitely provide an acknowledgement message for the request. This enables the MS to quickly re-start random access procedure so as to restore from the unsuccessful bandwidth request as soon as possible. As for the MS, it knows it should receive in next frame the acknowledgement message ACK, which indicates that the BS has already successfully received the bandwidth request message. If the MS does not receive the desired acknowledgement message from the BS, it knows that the previously sent request has gotten lost. Then, the MS re-sends a bandwidth request message, thereby substantially reducing unnecessary latency (namely, a period of time until the timer overflows).
Although the above solution eliminates unnecessary latency on the side of the MS, it still has a drawback, i.e., increasing the overhead. As for each MS request, the BS has to provide some resources to make the ACK response, which at least comprise an MS identification (MS ID) or connection identification and acknowledgement instruction. If it is carried by some message, the message transmission has its own format (header and message body). Therefore, the BS also has to allocate extra resource in MAP IE to inform the MS of where to receive the message. However, with respect to a majority of uplink bandwidth requests, when the BS receives a bandwidth request from a MS, it will timely reply a UL grant message to the MS. The MS can quickly receive the UL grant. In this case, acknowledgement for the bandwidth request becomes useless. Therefore, unnecessary overhead is caused.